home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
prog_bas
/
qbsvga.zip
/
QBSVGA.TXT
< prev
next >
Wrap
Text File
|
1996-04-22
|
13KB
|
251 lines
QBSVGA, version 1
"QBSVGA" is a set of subroutines/functions (and an "include file")
that can be used within QB programs to achieve SVGA graphic capability.
Much, but not all, of the standard QB graphic routines are emulated. To
be specific, the QBSVGA routines work best when the video system is not
just SVGA-capable, but VESA-aware as well. (I have yet to encounter an
SVGA-equipped system that is not VESA-aware, but I understand they exist.)
There are included stand-alone routines, VS.EXE and VS1.EXE, that you can
use to determine whether or not your system is VESA-aware and what video
modes you have support for. See VS.TXT for more information concerning
these routines. Whether or not a VESA bios is present on your SVGA card,
you must not only have hardware support for the video mode you want to
use, it must be supported by your VESA bios as well. (It's entirely
possible to have support in hardware for a video mode that your bios
cannot itself access. The routines supplied here do not use direct
hardware access, as opposed to the intrinsic QB graphic routines.) Further,
for the software to auto-detect a VESA video mode, your VESA bios must
provide the so-called extended information about that mode. (VS1 will
tell you whether or not this information is available. If VS1 informs
you that such information is unavailable for any given mode, there is not
necessarily any reason to worry. If QBSVGA fails to find such information
for any one particular mode, it will simply look for another one.)
Most of the documentation regarding the QBSVGA routines can be found
by reading the comments associated with each subroutine/function in
QBSVGA.BAS. This file simply makes some general comments and lists the
functionallity provided by QBSVGA. QBSVGA gives you access to up to 9
different SVGA modes/resolutions:
MODE = 14: 640 x 480 x 256
MODE = 15: 800 x 600 x 16
MODE = 16: 800 x 600 x 256
MODE = 17: 1024 x 768 x 16
MODE = 18: 1024 x 768 x 256
MODE = 19: 1200 x 1024 x 16
MODE = 20: 1200 x 1024 x 256
MODE = 21: 1600 x 1200 x 16
MODE = 22: 1600 x 1200 x 256
MODE = 23: 132 x 25 x 16 (text)
MODE = 24: 132 x 43 x 16 (text)
MODE = 25: 132 x 50 x 16 (text)
The mode integers listed above are the "QB-type" integers that you would
input to QBSVGA's analog of QB's screen statement. They are not necessarily
the actual hex numbers that your bios references (i.e., the video mode
specifiers that QBSVGA, via its subroutine FINDVESA, attempts to auto-
detect). Except for 0, and assuming that auto-detection works, if you
try to use a QB-mode not specified above, you'll get an 800 x 600 x 16
mode (if support for it can be found). (Using a mode of 0 produces the
same effect as QB's SCREEN 0 statement.)
The general method of using QBSVGA is to put the contents of
REGTYPE.INC at the top of your program, write your program, calling any
and whichever of the QBSVGA routines you need, and then put the contents of
QBSVGA.BAS at the bottom of your program. When you go to link your
compiled program, be sure and use the auxiliary library QB.LIB in addition
to whatever libraries you normally link with.
The usage syntax of the routines is similar to that with the
corresponding internal QB routines. The QBSVGA routine names are prefixed
with a "B" (for "bios") to distinguish them from their intrinsic QB
analogs. One difference between the intrinsic and QBSVGA routines is that
you must not leave out parameters unimportant to you in the calls to the
QBSVGA routines. Another difference is that, except for function BPOINT,
these routines must be accessed via QB's CALL statement. You can put
DECLARE statements at the top of your program if you wish to avoid this
detail, but there is still the matter of enclosing the arguments/parameters
in parentheses. Except for subroutine BCOLOR, in addition to the normal
call list parameters, each subroutine/function must be called/invoked with
", INREGS, OUTREGS" as the last two parameters in the call list. These
are the CPU register variables. They contain the data to be stored in the
CPU registers when an interrupt is called and the data output to the
registers when the interrupt call is finished, respectively. INREGS and
OUTREGS are the only parameters passed to the QBSVGA routines that are
not single precision (real) variables--except for the character string
input to BLINE to tell it what type of object to draw and the string input
to BPRINT. (An example MAIN routine, SIM.BAS, is included to show the
basic usage of the routines.)
The rest of this file gives a basic description of the different
routines supplied in QBSVGA.BAS.
SUB BSCREEN: analog of QB's SCREEN statement
(QB's SCREEN function is not emulated here. BSCREEN will
not change the video mode if the screen is already in the
mode you're requesting. In this situation, BSCREEN serves
merely to change active and displayed video pages.
Exceptions to this are when your inputting a video mode of 0
to BSCREEN, to achieve the same effect as QB's SCREEN 0
statement, or when auto-mode detection failed and you get
prompted for the bios video mode to use--see below. BSCREEN
should be called before any of the other routines--and then
again with a QB-type mode of 0 when you're all done.)
SUB BPSET: analog of QB's PSET statement
SUB BLINE: analog of QB's LINE statement
(QB's style option is not supported.)
SUB BCIRCLE: analog of QB's CIRCLE statement
SUB BCLS: analog of QB's CLS 0 and statements
(CLS 2 is not supported.)
SUB BCOLOR: analog of QB's COLOR statement
(There are no interrupt calls within BCOLOR; do not pass the
register variables to it.)
SUB BLOCATE: analog of QB's LOCATE statement
SUB BPRINT: analog of QB's PRINT statement
(See QBSVGA.BAS for discussion of differences in how this
routine formats output.)
FUNCTION BPOINT%: analog of QB's POINT function
(Note that BPOINT is a 2-byte INTEGER.)
SUB BVIEW: analog of QB's graphics VIEW statement
(Although BVIEW itself does not make bios calls, you still
need to pass the register variables to it so it can use
subroutine BLINE to handle the color and border options.)
SUB BPAINT: a not necessarily exact analog of QB's PAINT statement
(You should be able to use this subroutine to achieve the
same results that PAINT would give if it applied to SVGA
video modes. However, especially when painting the exterior
of objects, you may need to make multiple calls to BPAINT
with different (x,y) inputs.) Also, painting only occurs in
regions in which the pixel color is the same as the
background. This background color is either 0 or it is the
color of whatever the viewport (if active) was filled with.
Other than BSCREEN to set the video mode and various defaults, you
should not call any of these routines except BCOLOR, BCLS, BLOCATE, and
BPRINT *unless* you are in a graphics mode (QB-type modes 14 - 22). (And
to reiterate, don't call ANY of these routines without calling BSCREEN
first!)
There are two other routines that you do not necessarily need to be
concerned with, but at least one of which is worth discussing--especially
if your SVGA isn't a VESA SVGA. Subroutine FINDVESA inputs a QB-type
mode integer (see above) and first attempts to determine the presence of
a VESA bios. If it succeeds, it then tries to find a VESA video mode
supported in bios by your video card that gives the resolution and colors
associated with the QB-type mode. (If it finds one with the right
resolution but can only find such a mode with *more* than the number of
desired colors, the mode is accepted.) Note that this automatic mode
detection only applies to your video card. FINDVESA cannot determine
whether or not your monitor has the desired capability. If FINDVESA
determines that you don't have a VESA system or if, for whatever reason,
it cannot determine what bios mode gives you the resolution you want, it
will cause BSCREEN to prompt you for the bios mode integer (hexadecimal)
that gives you your resolution. If you know that your system supports the
mode you're requesting, input the hex number that your bios recognizes for
that mode. If you don't know what to input here, just press ENTER and the
program will STOP. (This prompt for input somewhat interferes with using
multiple calls to BSCREEN (which calls FINDVESA) to change video modes or
active/displayed pages repeatedly.) If by chance your graphics calls don't
really need as high resolution as the one for which FINDVESA couldn't find,
you can input the bios mode integer for a lesser mode if you know it. The
functionallity of BSCREEN and FINDVESA is incorporated in another included
stand-alone routine, FINDMODE. This program may be of more direct use
in regard to QBSVGA than VS or VS1. Run FINDMODE from the DOS command-line
with your desired QB-type mode integer specified as an argument and
FINDMODE will either tell you what VESA mode it found that corresponds to
your QB-type mode or it will tell you that it couldn't find such a mode.
This is the same behavior you can expect when you use QBSVGA with your
QB-type mode.
FINDVESA uses the function BIN$ to input a LONG integer (4 bytes) and
convert it to a binary number (represented by the text string BIN$). You
don't need to worry about this function unless you have some wish to use
it yourself.
There are a few caveats. First, there are a few Basic variables that
QBSVGA uses that your program must not use (unless of course you're
intentionally doing so as a "backdoor" method of by-passing some of QBSVGA's
simpler routines). These variables are:
ACPAGE (active video page)
DEFLTC (default color)
VESSUP (0 if VESA is supported/detected, 1 otherwise)
HMAX (zero-based horizontal screen resolution)
VMAX (zero-based vertical screen resolution)
VXL (x-coordinate of upper left viewport corner)
VYL (y-coordinate of upper left viewport corner)
VXR (x-coordinate of lower right viewport corner)
VYR (y-coordinate of lower right viewport corner)
VCOL (Color with which viewport was last filled)
VBORD (Color with which viewport border was last drawn)
(Originally, I circumvented this inconvenience by storing global data in
the "user communication area" at memory location 0:4F0. However, that was
not without its own dangers--there's no guarantee that some program that
your program SHELLs to DOS, for example, won't overwrite that data.)
Second, although I certainly don't mean to scare you away from using QBSVGA,
I must insist that you use it and the included utilities AT YOUR OWN RISK.
You may want to be careful about using video modes you don't have support
for. If you are not manually inputting bios video mode data to BSCREEN's
prompt for it, QBSVGA will not make any attempt to put your video adapter
into any mode for which it cannot confirm support. One problem is that it
is your video card that video support is confirmed for. If your video card
has more capabilities than your monitor, QBSVGA cannot detect that. In
particular, you may want to be careful using these routines if you have a
color-capable video card (I've not actually heard of a monochrome SVGA card)
but a monochrome monitor. (You may especially want to avoid using color
attributes other than 7 in that situation.)
QBSVGA has no particular hardware requirements, other than that an
SVGA card/monitor be present. (It may be faster on a 386/486/586 than a
286, for example, but it should still run on the 286. Incidentally,
because of the use of bios instead of direct hardware access, QBSVGA is
slower than the intrinsic QB functions.) The most substantial requirements
are that your operating system be at least compatible with standard PC/MS-
DOS and your computer be IBM compatible. (And I can't guarantee results
on computers with "nonstandard" bioses or SVGA cards/monitors--not that I
can guarantee them anywhere else either.) And, although I'm not necessarily
relinquishing copyright or the desire for credit of authorship, I don't have
any particular rules concerning what you do with this software, except for
perhaps selling it. (I didn't charge YOU for it, did I?) (But if not
sending me money is keeping you awake nights, by all means, send me some and
get some sleep!) (Distributing it with software that you've developed and
are selling would be okay--it would be flattering. I just don't think the
the presence of my software should influence your sales price.)
Glenn Stumpff
4960 Egret Ct.
Dayton, Ohio 45424
CIS: 73137,3537